Attribute DXL script setting values in other attributes

I've looked around, and it appears I'm in a bit over my head on this question. I'm hoping someone may have a simple solution, or even a resource I can refer to, in order to see if this is even possible.

1) First, solving all my problems immediately: Can you ever manipulate the DOORS attribute "Last Modified On"? I expect it's read only, but if I could change it somehow, no need to read further...

2) If not, I'm currently pulling in a value from another module via an Attribute DXL column, as I need to sync this data with HP Quality Center via the QC Integration engine for DOORS. It requires Attribute DXL in order to do that, rather than Layout. At the same time, I'd like to set a value in another attribute when the script runs and finds an update for a particular object, but I can't seem to reference another attribute outside of obj.attrDXLName in the Attribute DXL. So the tail end of the desired code that crashes DOORS right now looks akin to:

obj.attrDXLName = D
obj."Junk" = "Some string" (Junk being another attribute of the object)

Is this possible? Any help is greatly appreciated!
SystemAdmin - Fri Sep 17 16:29:05 EDT 2010

Re: Attribute DXL script setting values in other attributes
Mathias Mamsch - Tue Sep 21 02:41:01 EDT 2010

You can modify Last Modified On. If you change any attribute that affects change dates, the last modified on will be set to the server date. Otherwise I am pretty sure, you cannot modify Last Modified On.

Normally you should be able to modify other attributes in an attribute DXL. You need to make sure, that the module is opened in exclusive edit (and think about what to do if the module is opened read only). You can even modify the value of another DXL attribute:
 

obj."AnotherAttributeDXL" = "DXL"
obj.attrDXLName = "Dude!"
// before modifying a non-DXL attribute check for edit mode!
if (!isEdit current Module) halt
obj."Junk" = "Hello"

 


The above code works perfectly on DOORS 8.2. Maybe you should check for other crash reasons. Regards, Mathias

 

 

 


Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

 

Re: Attribute DXL script setting values in other attributes
llandale - Tue Sep 21 09:51:51 EDT 2010

In Mathias' code, I'd be tempted to use "canModify(obj)" instead of "isEdit(current Module)". But since you need to trap errors anyway, you can do away with that and just do this:

noError()
obj."Junk" = "Some String"
lastError()  // ignore any errors.

 


Back to your post. Last Modified On is not editable but you can set it to right-now by changing an attr value, then changing it back; but the module will need to be saved which should not be done in attrDXL.

 

 

string Valu = obj."Some Attribute"
noError()
obj."Some Attribute" = Valu "A"
obj."Some Attribute" = Valu
lastError()



But I suspect what you are after is some kind of attribute "LastTimeICheckedTheOtherModule" date attribute, settable via your DXL.

Am curious about what 'crashing DOORS' means. Your code may generate DXL errors but I don't see how it would crash DOORS.

And, of course, you need this at the top of all your attrDXL:



 

 

// v9.2.0.1 bug, cannot set AttrDXL values of a deleted object.  Fixed in v9.2.0.2
if (    isDeleted(obj)                                  and
        length(doorsInfo(infoVersion)) >=7   and 
        (doorsInfo(infoVersion))[0:6] == "9.2.0.1") halt

 

 

  • Louie

 

Re: Attribute DXL script setting values in other attributes
SystemAdmin - Tue Sep 28 13:42:52 EDT 2010

Mathias / Louie -
Thank you both for your contributions. I believe a few things I was trying at the time were causing issues. In answer to your question Louie, I think most of my problem was error trapping against an object that wasn't modifiable - I didn't have anything in place, which potentially crashes out the entire application in 9.2.0.0. Perhaps not trapping errors will crash the entire app? That's a question I don't have an answer to, but if you'd like any further questions answered for your curiosity, I'll be happy to do what I can.

Between the two sets of information, I've cobbled together what I need - thanks again!

Mike

Re: Attribute DXL script setting values in other attributes
llandale - Wed Sep 29 10:43:52 EDT 2010

SystemAdmin - Tue Sep 28 13:42:52 EDT 2010
Mathias / Louie -
Thank you both for your contributions. I believe a few things I was trying at the time were causing issues. In answer to your question Louie, I think most of my problem was error trapping against an object that wasn't modifiable - I didn't have anything in place, which potentially crashes out the entire application in 9.2.0.0. Perhaps not trapping errors will crash the entire app? That's a question I don't have an answer to, but if you'd like any further questions answered for your curiosity, I'll be happy to do what I can.

Between the two sets of information, I've cobbled together what I need - thanks again!

Mike

Trapping the errors should prevent the DXL window from opening and displaying lots of errors; and will allow the DXL code to at least finish. It should not prevent a 'crash' which to me means DOORS exits with/without an error message.

If it was indeed crashing and is indeed not crashing now, I'm VERY interested in the exact before and after code as knowning which functions can crash DOORS is very useful.

  • Louie

Re: Attribute DXL script setting values in other attributes
Mathias Mamsch - Wed Sep 29 10:52:36 EDT 2010

llandale - Wed Sep 29 10:43:52 EDT 2010
Trapping the errors should prevent the DXL window from opening and displaying lots of errors; and will allow the DXL code to at least finish. It should not prevent a 'crash' which to me means DOORS exits with/without an error message.

If it was indeed crashing and is indeed not crashing now, I'm VERY interested in the exact before and after code as knowning which functions can crash DOORS is very useful.

  • Louie

Haha Louie, I think you can crash 90% of the DOORS perms with invalid arguments, basically everything that does not have a bool, char or an integer as parameter (which are probably interpreted literally, and not referring to some heap object). So how do you keep track on which functions make DOORS crash? Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: Attribute DXL script setting values in other attributes
SystemAdmin - Wed Sep 29 12:06:37 EDT 2010

llandale - Wed Sep 29 10:43:52 EDT 2010
Trapping the errors should prevent the DXL window from opening and displaying lots of errors; and will allow the DXL code to at least finish. It should not prevent a 'crash' which to me means DOORS exits with/without an error message.

If it was indeed crashing and is indeed not crashing now, I'm VERY interested in the exact before and after code as knowning which functions can crash DOORS is very useful.

  • Louie

I had tried so many permutations, that I'm not 100% sure which piece of code would have been the problem in that exercise. However, attempting to refresh a module within an attribute DXL crashes DOORS consistently as of this morning in 9.2.0.0 so it seems. Just the standard I've used before, as below:
 

if(obj == last(m))
{
     refresh(m)
}

 


I've swapped out other commands for the refresh just to be sure it wasn't anything else, and they work fine.

It seems that attribute DXL is frustratingly finicky - rather than popping the inspection window to give data on an error, it just kills the entire DOORS process.